home *** CD-ROM | disk | FTP | other *** search
/ C/C++ 3D Game Tools / C-C++ 3D Game Tools.iso / ziptools / arj / nulib324.arj / NOTES next >
Encoding:
Text File  |  1993-03-16  |  3.5 KB  |  99 lines
  1. Programming notes (05-Nov-89) (updated 23-Aug-90)
  2.  
  3. -----
  4. Name:
  5. What started out as a NuFX viewer turned into a full-blown archiver.  It went
  6. from NuView to NuARC, which was reasonable... until I spoke to Andy Nicholas.
  7. Apparently he'd been warned against using the name NuARC, so I had to pick
  8. a new one.  "CShrink" seemed the most rational, since it is coded entirely in
  9. C and is meant to complement ShrinkIt.  However, L&L now owns the name
  10. "ShrinkIt", so I switched over to NuLib.  My other choice was "NuPak", but
  11. that's now a completely different (but compatible) program.  Sigh.  A rose
  12. by any other name would be full of thorns.
  13.  
  14.  
  15. -----
  16. Excuses:
  17. The code is written to be portable first, efficient second.  If you see a
  18. way to retain portability across a *wide* range of machines (from a //gs
  19. to a Cray) but increase efficiency, please let me know.
  20.  
  21. Because of the way this was developed (archive viewer -> simple extractor ->
  22. extractor with extra goodies, plus the NuFX standard kept changing while I
  23. was working), I haven't exactly followed top-down programming practices.
  24. It shows (wince).
  25.  
  26. Some of the procedures are rather long.  Good progamming practice dictates
  27. that no procedure should be longer than your screen; my screen (a Sun 3/50
  28. running X10) has 62 lines at the moment.  This is certainly no excuse for
  29. procedures in excess of 150 lines, but I have tried to break things down into
  30. pieces within the procedures themselves.
  31.  
  32. Some program-wide globals are used; most are boolean values or some special
  33. control variables that have to be visible across several files.  Probably
  34. the worst is "onebyt *pakbuf", which was used so that I didn't have to keep
  35. malloc()ing a 64K buffer every few calls.  It should be malloc()ed ONLY by
  36. routines called directly from main(), and should be free()d at the end of
  37. those procedures (which should cause execution to go back to main()).
  38.  
  39. Another bad one is tmpNameBuf.  I was worried about having multiple 1K buffers
  40. filling static storage (or the stack), so I made this... it is intended to be
  41. *very* temporary; don't make any calls to other NuLib procedures and expect
  42. it to survive.
  43.  
  44. This program is still under development...  But it's getting there.
  45.  
  46.  
  47. -----
  48. #ifdefs are generally structured as follows:
  49.  
  50. #ifdef UNIX      /* all UNIX systems come first */
  51. # ifdef BSD43
  52.   ...
  53. # endif
  54. # ifdef SYSV
  55.   ...
  56. # endif
  57.  
  58. #else            /* followed by micros, running GS/OS, MS-DOS, HFS, ... */
  59.  
  60. # ifdef APW
  61.   ...
  62. # endif
  63. # ifdef MDOS
  64.   ...
  65. # endif
  66. # ifndef APW    /* if nothing else is defined... */
  67. # ifndef MSDOS  /* this is included so that somebody doing a port */
  68.   /* +PORT+ */
  69.   ...           /* can easily figure out what needs to be altered */
  70. # endif
  71. # endif
  72.  
  73. #endif
  74.  
  75. Things that need to be altered when porting between systems are tagged
  76. with "/* +PORT+ */"
  77.  
  78.  
  79. -----
  80. #includes should be in this order:
  81.  
  82. #include "nudefs.h"
  83. #include <...>
  84. #include "..."
  85.  
  86. In ALL cases, nudefs.h should come first.  Generally speaking it is a good
  87. idea to have the system includes before any NuLib ones.
  88.  
  89.  
  90. -----
  91. UNIX doesn't really have a create_time field; it has accessed, modified, and
  92. "changed".  Modified gets reset when the data gets modified; changed gets
  93. reset by chmod, chown, link, mknod, rename, unlink, utimes, write, and
  94. truncate.  Anyway, the "modified" field is set what it should be, but I'm
  95. going to let the "changed" and "accessed" fields take care of themselves
  96. (in other words, I don't intend to modify them... besides, you can't change
  97. the "changed" field anyway).
  98.  
  99.